Only relevant to the internal feature `more_maybe_bounds`.

We no longer move trait predicates where the self ty is a ty param to
"the bounds of a ty param".

* The phrasing "only does something for" made sense back when this
  diagnostic was a (hard) warning. Now however, it's simply a hard
  error and thus completely rules out.
* The primary message was way too long
* The new wording more closely mirrors the wording we use for applying
  other bound modifiers (like `const` and `async`) to incompatible
  traits.
* "all other traits are not bound by default" is no longer accurate
  under Sized Hierarchy. E.g., traits and assoc tys are (currently)
  bounded by `MetaSized` by default but can't be relaxed using
  `?MetaSized` (instead, you relax it by adding `PointeeSized`).
* I've decided against adding any diagnositic notes or suggestions
  for now like "trait `Trait` can't be relaxed as it's not bound by
  default" /which would be incorrect for `MetaSized` and assoc tys
  as mentioned above) or "consider changing `?MetaSized` to
  `PointeeSized`" as the Sized Hierarchy impl is still WIP)

Having multiple relaxed bounds like `?Sized + ?Iterator` is actually *fine*.
We actually want to reject *duplicate* relaxed bounds like `?Sized + ?Sized`
because these most certainly represent a user error.

Note that this doesn't mean that we accept more code because a bound like
`?Iterator` is still invalid as it's not relaxing a *default* trait and
the only way to define / use more default bounds is under the experimental
and internal feature `more_maybe_bounds` plus `lang_items` plus unstable
flag `-Zexperimental-default-bounds`.

Ultimately, this simply *reframes* the diagnostic. The scope of
`more_maybe_bounds` / `-Zexperimental-default-bounds` remains unchanged
as well.